IBIS Macromodel Task Group

Meeting date: 12 May 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                              Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Nicholas Tzou
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:            Randy Wolff
                            * Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                              Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                         * Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Mike LaBonte unable to attend, Curtis Clark to take the minutes.

--------------------------
Call for patent disclosure:

- None


-------------
Review of ARs:

- Arpad, send email to IBIS reflector with ATM Task Group's recommendation to
  approve the PAM4 BIRD.
  - Done.

- Arpad, Submit [Define Package Model] BIRD to IBIS Open Forum.
  - Done, BIRD176, would like to discuss what happened.

- Arpad to review IBIS specification for min max issues.
  - In progress.


-------------
New Discussion:

- Arpad: We have several topics for discussion. I don't care about the order.
  - I would like to explain why a different version was submitted as BIRD176.
  - Walter has done work on the global ground problem.
  - Michael M., do you have anything on directionality?
- Michael M: A little bit.
  - We had a good discussion amongst some, including Bob Miller.
  - He had some questions about how the BIRD was put together.
  - He is not here today though.

BIRD 176 - Power Pin Package Modeling
  
- Arpad: I would like to describe what happened to BIRD 176.
  - In last week's meeting we reviewed draft 3.
  - We discussed it and decided it was ready for the Open Forum.
  - After that meeting I created a draft 4.
    - Draft 3 was well written, but I had issues with it and was still listed as
      an author at that time.
    - Based on internal discussions with Mentor colleagues.
    - Also, my own personal opinion that draft 3 was not acceptable.
    - Main issues for me:
      - Language that made some of the new capabilities optional.
      - This would have required GUI development from developers.
      - Would create confusion for users, especially with legacy models.
  - After I created draft four, we had a meeting amongst the authors.
    - Bob, Radek, Randy, and myself.
    - Used the editorial meeting time slot on Friday to review draft 4.
    - As a result of that, modified the document to create draft 5.
    - Submitted that to the Open Forum to become BIRD 176.
      - The authors considered going back to the ATM Task Group first.
      - In the interest of time, decided to submit it to the Open Forum.
      - Bringing draft back to this group for retroactive approval.
      - We have options moving forward if this group disapproves.
        - Vote it down in the Open Forum.
        - Create a new version, etc.
  - Even after draft 5 was prepared, some Mentor colleagues wanted Mentor to be
    removed from the authors.
    - I am no longer listed as an author.
    - Not for technical reasons.
    - Mentor may choose not to implement support for the current BIRD.
    - Would seem odd not to support a BIRD if listed as an author.
    
- Arpad: <sharing BIRD 176 on screen>
- Bob: I joined as an author.  It was a good BIRD.
  - Great editorial improvements were made over last week's draft.
  - However, I now have second thoughts.
  - What was stripped out in terms of "optional" language is what made it
    acceptable to me.
  - As now written, it is technically questionable:
    - Implied shorts may or may not exist.  May not be the best solution.
- Radek: The BIRD was discussed with great help from Bob.
  - I joined the discussion to close ambiguities.
  - I think the BIRD, as submitted, is not necessarily as questionable as Bob
    suggests.
  - It is trying to specify something previously undefined.
    - Either we go the direction of saying every pin must be in [Pin Numbers]
      or [Merged Pins], or we need the language we have now.
- Bob: What's proposed applies to all legacy versions.
  - It deprecates existing tool flows.
- Radek: It is not retroactive to all older versions.
- Bob: That's how you interpret it.
  - Implied pins will apply to all versions for the same reason.
- Radek: I still think Arpad should be in [as an author].
  - It's his and Mentor's decision.
- Bob: I have a proposal I think will resolve everything.
  - [on page 5 of the BIRD]
  - Rather than "...the following rules apply to..."
  - Change to "...the following rules are suggested for power and ground pins..."
  - This would cover Mentor's concerns and make me happy.
  - Would avoid locking ourselves into something technically invalid.
  - Since it applies to tools and not content of the specification, it could be
    made as an editorial change.
- Arpad: Please refrain from suggesting that it will resolve Mentor's concerns.
  - I think making it an option will create more concern at Mentor.
  - Tool might have to implement a GUI for choosing options.
  - It will make it even more expensive for tools to implement this BIRD.
- Bob: Add language like, "for all tools this suggestion provides a path..."
  - Most tools will just decide to only comply with this suggestion.
  - We can suggest how to process unspecified information.
- Arpad: I was an author up to the end.  I wrote most of the BIRD.
  - The concern I have about making it optional is that we specify no default.
  - If we don't, then the choice must be made by the user.
  - If there is a choice, there will be questions.
  - We have all the legacy models out there.
  - Now we will present a new choice to the user and model maker.
  - Is that new choice going to be useful for existing models, or just cause
    confusion and trouble?
  - The new choice may give worse results if the model wasn't written that way.
  - That's why I prefer the no choice rule.
- Bob: I understand, but a technically invalid choice is worse than leaving
       options open.
  - Most EDA vendors won't expend the energy to support all the choices.
  - Choices take time to implement anyway.
  - You mentioned defaults.  We could add "suggested as the default choice..."
  - Then it doesn't undermine existing tools.
  - Deprecating most tool flows anyway, because this applies retro-actively to
    older models.
- Arpad:  You mentioned that this would invalidate a lot of existing models.
  - We discussed that in our meeting.
  - There aren't that many models that use [Pin Mapping].
  - This rule only applies to them.
  - If the [Pin Numbers] lists all the [Pins], then this won't be an issue.
  - Randy mentioned the spatial resolution of the bedspring models.
    - If he wants to make more accurate models he can control the groups of
      pins that are shorted.
  - It is true that the resolution of the bedspring model might be reduced by
    the shorts that this BIRD implies.
  - RLC package models aren't that accurate anyway.
  - May not be a perfect solution, but RLC matrices are imperfect to start.
  - Bedspring issue may not reduce overall accuracy anyway, given RLC.
  - My impression from the discussion was that Randy was satisfied with this as
    an interim solution.
  - When the accuracy of these is no longer sufficient, we should have the new
    interconnect proposal by then.
  - We should try to keep this interim solution as simple as possible.
- Bob:  I think my suggestion is a better solution.
  - Your argument is that this is already a defective solution, so we can put
    another defective solution in IBIS.
  - I would argue that, even if Randy wants it, a defective solution is worse
    than no solution.
- Arpad: My understanding is that Randy thinks it works as an interim solution.
- Bob: He was willing to accept "suggested" and not the mandated solution.
  - EDA vendors can adopt the "suggested" language and not corrupt IBIS.
  - Otherwise we may be mandating something that may not be technically valid.
  - IBIS is a data spec. not an EDA tool spec.
  - Randy can choose to group pins as you suggested.  That explicit merging is
    okay if he chooses to do it.
  - But implicit merging could still exist with [Merged Pins] and is a problem.
- Radek: Unless there is a clear requirement that any [Pin Mapping] pin that is
         not in [Pin Numbers] must be in [Merged Pins].
  - That's one way of removing ambiguity.
  - I agree with Arpad's statement that if we just change it to "suggested"
    behavior then no default is specified.
  - Last week's version did have a default behavior.
  - The optional nature was stressed by the statement that the tool, "may provide
    the option for the user to select."
  - There were no ambiguities.
- Arpad: I'd like to ask others listening, what should be our next step?
  - We could recommend voting the current BIRD down.
  - We could submit a second BIRD.
  - What should we do in the upcoming weeks?
  - It was submitted to be available for the next Open Forum meeting.
- Walter: I make a motion that this group recommends that the Open Forum table
          this BIRD in the Open Forum until ATM comes up with a recommendation.
- Bob: Clarification, the motion to table would be made at Open Forum, not here.
- Walter: That's right, it's not to table it here.
  - Though I would table it here for now.
  - I recommend that this group recommends to the Open Forum that this BIRD be
    tabled in the Open Forum meetings.
- Radek: I don't think that's a good direction.
  - We are here to provide an advisory function.
  - Open Forum may request ATM to provide input.
  - Open Forum can make decisions regardless.
  - Open Forum can table, reject, etc., on its own.
- Arpad: We have a motion, do we have a second?
  - Do we need to restate the motion again?
- Michael M: It would help.
- Walter: I move that IBIS ATM recommends to the Open Forum that any further
          discussion on BIRD176 be tabled in the Open Forum meeting.
- Arpad: Seconds?
- Curtis: I second.
- Arpad: Anyone opposed to tabling this BIRD in the Open Forum.
- Bob: I oppose.
  - That motion can be made at the Open Forum meeting.
  - We can continue discussing this at the ATM.
- Michael M: Was your intent to recommend to the Open Forum that this be tabled?
- Walter: Correct.
- Arpad: Do we need a roll call vote?  Not used to having objections.
- Michael M: Unless the motion is amended and seconded or withdrawn.
  - Hence my clarification regarding the recommendation.
  - Bob, you don't object to a recommendation from this body to the Open Forum?
- Bob: This resolution should not override the fact that we might reach a 
       consensus anyway.
  - Not a meaningful motion.
- Walter: I withdraw the motion.
  - I think we've invested too much time on this in this meeting.
  - The authors of this BIRD should get together and come up with something they
    all can agree to in a clear manner.
  - The whole purpose of this BIRD was to get into IBIS 6.1.
  - That clearly isn't going to happen in the current state.
  - I'm now making a motion that we table this BIRD in this meeting.
- Michael M: I'll second.
- Arpad: Anyone opposed to tabling the discussion on this BIRD until the authors
         come to some decisions?
- Bob: I'll oppose the motion so we have to have a vote.
- Vote to table:
  - 4 yes (ANSYS, Mentor, Intel, SiSoft)
  - 2 no  (Teraspeed, Micron)
  - 1 abstention (Keysight)
  - The BIRD is tabled.
  
- Arpad: Okay, Walter.

Problems with Global Ground in IBIS:

- Walter: I have ten minutes to solve the problem of global ground.
  - We've been fighting this issue in the interconnect meetings.
  - We need to cleanup IBIS 6.0.
  - <sharing his global ground power point presentation>
  - We've decided in interconnect meetings, as long as global ground doesn't
    show up in your interconnect then everything is okay.
  - Global ground is implied in the schematic:
    - Simulators don't keep track of the potential differences directly.
    - They keep track of single values representing node voltages.
    - Each of those single values is relative to simulator global ground.
    - As long as no current goes there it's okay.  Packaging modeling is good.
  - Problem occurs when you look into IBIS 6.0.
    - <showing terminator model diagram - page 62, IBIS 6.0>
    - What does that little ground symbol mean?
    - "GND" is all over the place.
    - Even the words "global ground" are found here and there.
    - How do we fix these?
    - Terminator model diagram is the biggest headache, but easiest to solve.
      - This ground symbol was an editorial problem introduced going from 5.0
        to 5.1.
      - The original drawing had "GND" not some global ground symbol.
      - Problem is that to some of us "GND" looks like it might mean node 0.
      - IBIS-ISS, for example has GND meaning global ground since it is
        inherited from HSPICE syntax.
    - But that was not the original intent of all the "GND" references in IBIS.
    - I think GND was meant to imply the signal name GND in the [Pin] section.
    - I think even in the original diagram GND was wrong.
- Arpad: I think you're correct that they are tied together if it's the same
         voltage, but it's drawn that way for something like ECL where those
         voltages aren't the same.
- Bob: You had it right that that symbol should just be local ground reference.
- Walter: Yes, but what would local ground reference be other than [GND Clamp
          reference] or [Pulldown reference]?
  - There is no other reference we can define in IBIS.
  - I sent out an IBIS 6.0 with a bunch of changes.
  - Wherever we have GND it is confusing.
  - If we just change those to VSS it clarifies things tremendously.
  - We should avoid using "GND" unless it's in a space where it is explicitly
    defined (e.g. as in [Model] name).
  - I ask people to just go through all those changes.
  - If we just make it clear that "GND" is local ground reference which is in
    turn defined as connected to pins with a specific signal name that are 
    model ground.  ([GND Clamp reference] or [Pulldown reference])
  - Could go through and make the changes I've recommended in this document
    and review them carefully.
  - Any questions?
- Bob:  We have to go through this carefully.
  - Pages 53, 54, 55, we have to be very careful.  That was intended to be a
    local ground reference or [Pulldown reference].
- Radek: Yes, we have to be careful.
  - I think there is nothing wrong with "GND" if it is known that it is not
    assumed to be global ground.  That can be explained.
  - To be free of global ground is relatively easy.
  - Local ground still exists for C_comp.  We can't avoid it unless we recommend
    the other C_comp_xxx.
  - Making the statement that GND and [Pulldown reference] are the same
    invalidates keywords.  We don't want to make them identical when [GND Clamp
    reference] or [Pulldown reference] were able to be different.
- Walter: Yes, that's the hardest one.
  - If you have distinct [GND Clamp reference] and [Pulldown reference] terminals
    then we could define a precedence ([GND Clamp reference] first or vice versa).
  - That's the only one where the local reference is not obvious.
- Radek: That's not the current interpretation of the spec.
  - You can have a local ground reference say 1V (need not be zero).
  - You can have a Pulldown ref at 2V (1V over local ground).
  - You can have a ground clamp ref .5V (.5V over local ground).
  - Hard to get out of that.
- Walter: Your statement is confusing me.
  - You're saying you can have a model with 3 terminals (pd_ref, gc_ref, and local
    ground reference).  What we said in packaging is that we can only use as
    reference voltages signal names that are pins of [Model] GND or POWER.
  - That means in the [Pin] list there has to be a signal name that corresponds to
    that particular local ground terminal.
  - How do we associate that particular signal name in the [Pin] list with that
    particular local ground terminal in the [Model]?
- Radek: I don't know, but we have to handle what we have in the current spec.
- Walter: What do we have in the current spec with C_comp?
  - In the current spec it's hooked up to "GND."
- Radek: Yes.
- Walter: GND is not local ground, GND is the signal name.
- Radek: Or the model name.
- Walter: Ah, but in other places we use VCC and VDD not POWER for the node.
  - We imply in many places that VDD is the component [Pin] signal name.
  - If we simply make the assumption that "GND" is just one of the signal
    names in the [Pin] list that is on model GND.
- Radek: I would like that solution, but we still have the existing
         interpretation to address.
- Walter: Show me where there is an interpretation that C_comp goes to a
          local ground that is neither [GND Clamp reference] or
          [Pulldown reference].
- Radek: If we have a picture anywhere that includes Pulldown, pullup and
         C_comp then the C_comp is clearly not connected to [GND Clamp
          reference] or [Pulldown reference] but to the GND node.
- Walter: Yes, GND node, is it the signal name or the HSPICE interpretation?
- Radek: I'm not talking about the global ground interpretation.
  - I'm talking about GND being a different node voltage with respect to
    [GND Clamp reference] or [Pulldown reference].
- Walter: Here's a picture (ISSO PD picture).
  - Pulldown goes to GND or [Pulldown Reference].
  - [Pulldown Reference] here is a voltage level.
  - That's when it's a DC voltage level, but when it gets hooked up to the rail
    voltage it's the local ground.
- Radek: If [Pulldown Reference] is not zero, then you have a difference between
         that and GND voltage level.  That will affect the simulation.
- Walter: No, when [Pulldown Reference] is something other than zero, it's
          saying the rail is something other than zero.
  - When someone says [Pulldown Reference] is .1V that means the rail terminal
    is .1V, so the local ground is .1V.
  - The [Pulldown Reference] is the voltage put on the rail when the IV curves
    are measured.
- Bob: Yes, but it's relative to zero volts.
  - .1 is relative to zero and therefore zero is defined as the meaning of GND.
- Walter: No, zero is the chassis ground at this point.
  - We have this fundamental problem with the reality of the silicon and the way
    some people are interpreting the IBIS text.
  - There's no reality to the statement that when you're doing a measurement of
    the I/V curves.
  - If you say the [Pulldown Reference] is 0.1V, that means the rail on the
    silicon is at .1V.
  - That .1V isn't relative to any other node in the silicon.  It's relative to
    some test fixture you're measuring from...
- Arpad: We're 15 minutes over time.  Now would be a sufficient place to stop.
  - Walter made a point of describing his initial work here.
  - We need to dive in and review things.
  - For today that should be enough to introduce the problem.
- Walter: This is excellent, thank you.
- Bob: By the way, this is good work mostly.
- Walter: We're having a debate, when you say [GND Clamp reference] is .1V, what
          does that mean?
- Bob: It means how the model was extracted.
- Walter: It doesn't say what the .1V is relative to.
- Arpad: I would say it's relative to the VRM module.
  - Like I said, I think we should stop here.
- Walter: I think it's reference to chassis ground.
  - Really important, there's no capacitance to chassis ground.
  - The capacitance is to the local rail ground, which is .1V.
  - The capacitor itself is in the buffer.  How could it have a
    capacitance to the chassis?
  - Doesn't it make sense that C_comp, that capacitor in the buffer,
    is a piece of metal that has capacitance to some copper of local
    ground and not capacitance to the chassis?
- Arpad: Alright, I highly recommend that we stop for now and continue
         in email or next week.
  - Thanks for joining everybody.
  
-------------
Next meeting: 19 May 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
